Many modern electronic hardware devices are controlled by a central processing unit (CPU) executing a program stored on a storage medium. Due to their manufacturability and versatility, CPUs nowadays are used in pagers, cell phones, digital subscriber link (DSL) modems, automated teller machines, and other devices. The specific functionality of the CPU-controlled devices is achieved by a suitable programming of the CPU. This approach is very flexible in that it allows the devices to be upgraded by upgrading the software program stored on the storage medium. Furthermore, if the storage medium is rewritable, an upgrade is possible without replacing any hardware, by simply recording a new version of a software program on the rewritable storage medium of the hardware device.
While upgrading a single CPU-controlled hardware device is a relatively simple task, it becomes considerably more difficult when the devices are a part of a specialized network, for example a network of automated teller machines, or a wireless communications network, or a DSL data network having many DSL modems. In addition, the hardware modules servicing a data network, such as network routers, need to be upgraded from time to time as well. For convenience, a specialized CPU-controlled networked device such as an automated teller machine, a wireless communication device, a DSL modem, a cable television set box, or a network router, upgradeable with an updated version of a software program (SP), is termed hereinafter a hardware device (HD).
Not only are the HDs generally expected to have short down times, but all the devices belonging to a particular network, the upgraded ones and the ones yet to be upgraded, are expected to behave in a certain pre-defined way in response to a certain standard command received from a control center of the network. Furthermore, an unsuccessful upgrade attempt can lead to a remote HD lockdown which would require the presence and intervention of a field technician. Since the amount of remote HDs in a network can reach hundreds and thousands, the network upgrade task can be daunting unless the upgrade procedure is automated.
An automated update procedure has been implemented for personal computers (PCs) on a network such as a local area network or the Internet. It is well known, for example, that a Microsoft™ Windows™ operating system software update can be performed over the Internet, by downloading a setup software package, which contains a full set of software modules and a setup program, to a hard disk of a Windows-running PC, and running the setup program on that PC. Among other steps, the setup program typically instructs the PC to do the following: determine its present software and hardware configuration; select, out of a standard set of modules downloaded, the software modules that match the current PC configuration; install the matching modules; and delete unnecessary components and temporary files. Most of the steps can be performed in an automatic mode, that is, in a mode not requiring the end user intervention, and can be run as a background task. Still, it is common to implement a warning to the end user, if a restart of the PC is required to complete the operating system software update.
Even though such an automated PC software update procedure is related to an upgrade of a microprocessor-equipped device over a network, it is unsuitable for upgrading an HD having far less processing power than a PC. In order to be able to download the entire setup software package, high connection speeds and large amounts of available memory of the local device are required which the HDs considered in the present invention do not usually have. Moreover, the CPUs of such HDs are simply not capable of handling complicated multi-tasking operations required to perform a software update in a way it is done for PCs. Not only that, but the requirements of continuous operation with limited down times, as well as the requirements of overall network robustness and reliability, are generally more stringent for a network of HDs then they are for a network of individual PCs. All these limitations preclude the PC software update method outlined above from being used for an upgrade of HDs over the network.
One method of solving the problem of updating software of cellular phones is described in US Patent Application Publication No. 2006/0195835 by Olrick et al., which is incorporated herein by reference. Olrick et al. suggest to solve the abovementioned problem of lack of CPU processing power and CPU memory required for performing the upgrade of cellular phones, by installing specialized computer based stations dedicated to the phone upgrades, in which the cellular phones to be upgraded would be loaded similarly to a way a compact disk loaded into a PC, that is, by using a specialized retractable tray the cellular phones would fit into. These upgrade stations are connected, through a general-purpose data network, to a central computer having a database of new cellular phone programs. The stations could be installed, for example, in cellular phone retail shops.
Undesirably, the method of Olrick et al. entails considerable expenses related to building a network of the upgrade stations and training retail shop representatives to use these stations to upgrade the phones. Furthermore, it requires the end users of cellular phones to physically deliver the phones to the retail shops, which is of course inconvenient for the end users.
A method of upgrading software of network elements in data and communication networks is taught in U.S. Pat. No. 7,266,819 by Helgesen et al., which is incorporated herein by reference. In a preferred embodiment of U.S. Pat. No. 7,266,819, the upgrade process of network elements in a communication system is controlled from a certain workstation, herein termed an installation workstation, which runs a script controlling a network element (NE) to be upgraded. Turning now to FIG. 1, a block diagram of such a script is presented. At a step 4, the software package containing required software elements is downloaded from the installation workstation to the NE. At a step 5, a check of compatibility of the downloaded software package with hardware and software of the NE is performed to ensure that the new software is loadable into the hardware, and that the new software is compatible with the one presently installed. If the downloaded software is found to be compatible with both the software and the hardware of the NE, then, at a step 6, a check of operability of the NE is performed; if the NE is found to be operable, then, at a step 7, the present software is backed up in a memory medium of the NE and, at a step 8, the set-up constants and other data stored in the memory medium of the NE are converted for use with the new software. Then, the installation workstation of the NE assumes an exclusive control over the NE, and the activation of the new software is executed at a step 9. If the activation is successful, the exclusive control over the NE is released and, at steps 10 and 11, post validation checks are performed in order to test if the new software is working properly. If the installation was unsuccessful, or if the post validation checks find the NE non-operational, a rollback procedure 12 is performed. Then, before finishing the procedure, a cleanup 13 is performed. The full control over the NE during activation of new software is necessary to avoid conflicts and interferences with other network elements.
To understand the limitations and disadvantages of the method of Helgesen et al., the following example may be considered. A wireless carrier (WC) plans to roll out a new service, for example video clips, on their existing infrastructure. The WC already has remote probes deployed, and the supplier developed a version of a software (Version A) that can test the new service. The deployment has the following constraints: (1) the WC starts the roll-out in a manual fashion, upgrading one or two probes and verifying their real-life performance, and then upgrades all the remaining probes automatically, upon the successful verification; (2) the WC expects the delivery of a next version (Version B) of software in about six months, and it is very important to prevent an upgrade to Version A of the software after six months have passed; (3) the WC requires the upgrade to be performed only during maintenance hours, e.g. between 12 am and 6 am at night, to ensure that the upgraded remote probes can be tested at more challenging conditions, that is, during the peak hours of the wireless network.
Within the framework of the method of Helgesen et al., the constraints (1) to (3) above cannot be fulfilled. Indeed, the method of Helgesen et al. is not flexible enough to provide an option of upgrading individually selected phones on a trial basis. Further, disadvantageously, the method of Helgesen et al. does not provide for a possibility to upgrade to a specific version of a software which will expire after a certain time, e.g. in six months in the example above, neither does it provide a possibility to limit the automated upgrade to a pre-defined time window. Yet further, disadvantageously, the method of the prior art includes the step 4 of downloading the software to the NE, which is undertaken before determining compatibility of the software with the existing software and hardware of the NE being upgraded, at steps 5 and 6. If the software is found to be incompatible, the extensive and resource-consuming rollback procedure 12 has to be executed. Furthermore, the method of Helgesen et al. does not provide a means for taking into account an unsuccessful past upgrade of a particular device, when rolling out a new software upgrade across the entire network, which includes many devices.
Accordingly, it is an object of the present invention to provide a method allowing one to systematically roll out new software, revision by revision, over a network of HDs differing by hardware capabilities and by a length of field service. Advantageously, the method of the present invention performs all the necessary checks, including the past upgrade failures, before downloading a newer version of a SP to an HD thus saving valuable network resources. Further, advantageously, the method of the present invention is applicable to a wide variety of HDs which do not necessarily have computing resources sufficient to perform local software backup or de-installation.